An IP Multimedia Subsystem (IMS) is a new multimedia service form, which can meet requirements of terminal customers for more innovative and diverse multimedia services. FIG. 1 is a network structural schematic diagram of an IMS system in the related art. All functions in FIG. 1 are described below.
A Call Session Control Function (CSCF) is a core function entity of the IMS system and primarily responsible for processing signal controlling in a process of multimedia call session. The CSCF manages user authentication of an IMS network and QoS of an IMS bearing plane, and cooperates with other network entities to control a Session Initiation Protocol (SIP) session and perform service negotiation and resource allocation. In the FIG. 1, the CSCF includes a Proxy CSCF (P-CSCF) and a Serving CSCF (S-CSCF).
The P-CSCF is a unified entry point for the IMS to access a network. All session messages which are initiated by an IMS terminal and end in the IMS terminal are sent to other network elements of a network side through the P-CSCF.
The S-CSCF is a core of the IMS and locates in a home network. The SCSCF implements a registration function and session control of an User Equipment (UE).
An Access Transfer Gateway (ATGW) is an anchoring point of calling, by a VoIP, user media.
In the IMS network, an Access Transfer Control Functionality (ATCF) system mainly functions in supporting a VoIP call accessing by PS, receiving a switching request from an MSC Server during the call, switching the call to a CS network, and keeping call continuous during a switching process.
If the ATCF sends an invite request and receives multiple response messages (including 18×, 200 responses) corresponding to the invite request, wherein tag field values in To headers of these response messages are different (each to-tag represents a different call leg), then it is considered that this is a Forked call. For an application scenario of the ATCF, usually the S-CSCF has a fork, receives multiple response messages of a called side and transparently passes them to the ATCF, which causes the Forked call to appear in the ATCF.
According to a 3GPP 24.229 requirement, an IMS network element needs to support multiple response messages transparently passing the Forked call and a final call of the Forked call. But 3GPP 24.237 does not describe media anchoring and playback flow of the Forked call in a ringing state of the ATCF. For the Forked call in the ringing state, if the multiple response messages (having different to-tags) of the called side carry different playback media information, anchoring media resources in an usual way can only anchor the media in a certain response, then a simultaneous playbacks of multiple Forked calls in the ringing state cannot be implemented.